Billing profile manager

ABSTRACT

A billing profile management system and method is provided. In an embodiment, a billing profile manager is configured to cooperate with an existing network and prepaid server. The billing profile manager is configured to modify the prepaid server and maintain a billing profile for each subscriber that is separate from the billing profile on the prepaid server and which can ultimately override the prepaid server. Additional billing functionality to an existing network and prepaid server is thereby provided.

The present specification is a National Stage Entry of PCT/CA2007/001604filed Sep. 13, 2007, the contents of which are incorporated herein byreference.

FIELD

The present invention relates generally to telecommunications and moreparticularly relates to a billing and profile management in atelecommunication system.

BACKGROUND

With worldwide network bandwidth becoming ubiquitous, an ever-expandingrange of services which are carried via those networks is emerging.Growth is not expected to slow down.

Along with those applications and services is the need to process thefinancial transactions related to the use of those services. Currentbilling and other financial related systems can be improved upon inorder to appropriately support and reflect the nature of the service.

SUMMARY

The specification provides, amongst other things, a billing profilemanagement system comprising a network configured to a fulfill servicerequest on behalf of a mobile device. The system also comprises aprepaid server connected to the network. The prepaid server isconfigured to debit a prepaid account associated for the mobile devicebased on fulfillment of the service request by the network. The systemalso comprises a billing manager connected to the network and theprepaid server. The billing manager is configured to maintain anotheraccount associated with the mobile device. The billing managerconfigured to update the prepaid account based on billing criteriaassociated with the mobile device.

The specification also provides, amongst other things, a billing profilemanagement system comprising a network configured to fulfill a servicerequest on behalf of a mobile device and a billing manager connected tothe network. The billing manager is configured to maintain a pluralityof different billing profiles associated with the mobile device. Each ofthe billing profiles includes at least a billing entity and a criterionfor selecting the billing profile. The billing manager is configured toselect an appropriate one of the billing profiles based on the servicerequest from the mobile device and to bill the billing entity respectiveto the selected billing profile. The billing profile management systemcan further, optionally, include a prepaid server connected to thenetwork configured to debit a prepaid account associated for the mobiledevice based on fulfillment of the service requests by the network. Thebilling profile management system can further, optionally, include anevent record based billing system connected to the network configured todebit a post-paid account associated with the subscriber based onfulfillment of the service requests by the network. In this case thebilling manager is configured to modify the prepaid or postpaid accountaccording to the billing profile in order to allocate a chargeassociated with a service supported by the mobile device and tooptionally cause the network to selectively permit or deny the servicerequest.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic representation of a billing profile managementsystem.

FIG. 2 is a flowchart depicting a method for emergency top up of aprepaid account.

FIG. 3 is a flowchart depicting a method for topping up prepaid account.

FIG. 4 is a flowchart depicting a method for management of a pluralityof billing profiles.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Referring now to FIG. 1, a billing profile management system isindicated generally at 50. System 50 comprises at least one mobiledevice 54 that is operated by a subscriber S. Mobile device 54 can be amobile telephone or an enhanced device that includes functionality of atelephone, email pager, web-browser, music player, or video player.Depending on the functionality of device 54, device 54 is operable toaccess a plurality of network services such as voice, text, video,music, web-browsing, mapping, email and variations and hybrids thereofand enhancements thereto.

Mobile device 54 is associated with a home network 58 that comprises atleast one wireless base station 62 connected to a home location register(HLR) 66 and a mobile switching center (MSC) 70. Subscriber S can thusaccess home network 58 using mobile device 54 in the usual manner. Thecomponents shown in home network 58, and their interconnection, aresimplified for purposes of explanation. Those skilled in the art willrecognize that network elements such as the HLR will evolve in a mannerprescribed by standards and specifications put forward by organizationsincluding, but not limited to, the 3GPP, 3GPP2, TIA, ITU, ANSI, andETSI. For example, the HLR will evolve to provide the functionalityprescribed by a Home Subscriber Server (HSS) without diluting the scopeof the disclosure. Those skilled in the art will also recognize that themobile device 54 can be connected to other network elements via awireless base station 62 for the purpose of invoking or receivingservices, including but not limited to, a SGSN (Serving GPRS SupportNode), PDSN (Packet Data Serving Node), or WLAN (Wireless Local AreaNetwork) Access Point.

System 50 also comprises a billing profile manager 74 that comprises agateway 78 connected to a billing management engine 82 and to a billingmanager database 86. Billing profile manager 74 can be operated by thesame entity that operates home network 58 or can be independent asdesired.

System 50 also comprises a prepaid server 90 that itself comprises aservice control point (“SCP”) 94 and an account balance database 98.Prepaid server 90 implements prepaid services on behalf of prepaidsubscribers to home network 58 in the usual manner, such thatsubscribers can make prepaid calls via network 58. In general, thefunctionality of SCP 94 and account balance database 98 will now bereadily understood by those skilled in the art. Prepaid server 90 can beoperated by the same entity that operates home network 58 or can beindependent as desired.

As will be discussed further below, billing profile manager 74 isgenerally configured to provide a plurality of flexible billing optionsand methodologies for the operator of network 58. In certainembodiments, such flexible billing options and methodologies areimplemented without requiring material modification to existinginfrastructure within network 58 and/or server 90.

In one embodiment, where subscriber S is a prepaid subscriber on network58, then system 50 can be used to permit subscriber S to make emergencytop-ups to the prepaid balance associated with the prepaid account usedby subscriber S and that is maintained by prepaid server 90. Referringnow to FIG. 2, a method for emergency top-up is depicted in the form ofa flow-chart and is indicated generally at 200. Method 200 can beperformed using system 50, though it should be understood thatvariations to both system 50 and method 200 are contemplated.

As previously discussed, method 200 assumes that subscriber S is aprepaid subscriber on network 58, and that the account balance forsubscriber S is maintained on prepaid server 90 in the usual manner.Beginning first at step 210, a request is received to make a call from amobile device or to receive a call at a mobile device. (Note that whilethe request is for a call this embodiment, in other embodiments therequest can be to invoke or receive any service that is available fromdevice 54 and supported by network 58). In relation to system 50, such arequest is made by subscriber S using device 54 to dial a number, and isreceived by HLR 66 and MSC 70 in the usual manner. At step 215 MSC 70checks prepaid server 90 to ascertain the prepaid balance associatedwith subscriber S. At step 220, if it is determined that thesubscriber's prepaid balance is sufficient, then method 200 advances tostep 225 where the prepaid call is processed and monitored in the usualmanner.

However, if at step 220 it is determined that the prepaid balance is notsufficient then method 200 advances from step 220 to step 230 and amessage (for example, via short message service (“SMS”)) is sent todevice 54 indicating that the account is depleted. A typical criterionfor insufficient balance would include a prepaid account with a balanceequaling zero, but a balance greater than zero could also be set as thecriterion, where such a balance is beyond some minimal amount needed tocomplete the call request made at step 210. Those skilled in the artwill recognize that there are a variety of means and mechanisms wherebya ‘low balance’ indication can be provided to the subscriber S via themobile device 54 including, but not limited to, voice-basedannouncements provided by Intelligent Network (IN) elements such asIntelligent Peripheral (IP) devices and tones provided by the MSC 70.

Next, the method 200 advances to step 235, at which point adetermination is made as to whether subscriber S requests an emergencytop-up. In a present embodiment, it is contemplated that gateway 78 isan Unstructured Supplementary Service Data (“USSD”) gateway configuredto receive USSD codes entered into device 54 by subscriber S, and whichare automatically routed from HLR 66 to USSD gateway 78. Thus,subscriber S will have been previously informed of a predefined-USSDcode (e.g. *999#) that represents a request for an emergency top up ofthe prepaid account associated with subscriber S in prepaid server 90.If subscriber S does not enter the predefined-USSD code at step 235 thenmethod 200 ends. However, if subscriber S does enter the predefined-USSDcode at step 235, then method 200 advances from step 235 to step 240.

Next, at step 240, a determination is made as to whether subscriber S ispermitted to make an emergency top-up to the prepaid account associatedwith subscriber S. Such a determination can be based on a subscriptionprofile associated with subscriber S and assessable via the billingprofile manager 74. Those skilled in the art will recognize that thesubscription profile may be stored in a variety of network elementsincluding the HLR 60 or another database or data warehouse resident inthe network operator's operational support system (OSS) or BusinessSupport System (BSS). The subscriber profile associated with subscriberS may also be accessed via a profile server implemented according to theteachings of U.S. patent application Ser. No. 11/516,308 entitled MethodAnd System For Active Profile Server filed Sep. 6, 2006, the contents ofwhich are incorporated herein by reference. If the determination at step240 is “no” then method 200 ends. If the determination at step 240 is“yes”, then the method proceeds to step 242.

At step 242, the method determines the number of serial emergencytop-ups that have been applied or if the accumulated top-up debit storedin the billing manager is less than a given threshold. For example, ifthe serial emergency top-up counter is set to three, a given subscriberS would be permitted to apply two emergency top-up pursuant to themethod 200. As another example, if the accumulated emergency top-updebit threshold is set to $11.00, a given subscriber S would bepermitted to apply an emergency top-up only if the top-up debit is lessthan $11.00. If the determination at step 242 is “no” then method 200ends. If the determination at step 242 is “yes”, then the methodproceeds to step 245. In an optional manifestation of the method, amessage indicating why the emergency top-up request was not accepted maybe sent to the subscriber (e.g. via SMS).

At step 245, in response to the USSD code, a top-up debit is applied. Atstep 245, gateway 78 will have passed the top-up request and an identityof subscriber S along to billing management engine 82, which will accessbilling manager database 86 and record that subscriber S has requestedan emergency top-up and will debit an account maintained on billingmanager database 86 that reflects a predefined emergency top-up amount.The predefined amount is not particularly limited, and can be based onsimple increments that correspond to amounts associated with prepaidcards that are issued by network 58, and/or can be an amount that isspecifically requested according to the request (e.g. the USSD request)made at step 240. For example, the predefine USSD code could include afield whereby the subscriber S indicates an amount for the emergencytop-up. For example, *999#5, would represent a request for an emergencytop up of five dollars.

Next, at step 250, the top-up credit will be propagated to theappropriate entity in the system. In system 50, engine 82 will send aninstruction to prepaid server 90 indicating that the prepaid accountassociated with subscriber S has been credited an amount equivalent tothe predefined amount discussed earlier.

At this point, after performance of step 250, system 50 can beconfigured so that method 200 ends and now subscriber S can initiate orreceive a new call, or, system 50 can be configured so that method 200returns from step 250 to step 215 whereby system 50 will assume thatsubscriber S is still attempting to make a call in accordance with theoriginal request received at step 210.

Referring now to FIG. 3, a method for topping up a prepaid account isdepicted in the form of a flow-chart and indicated generally at 300.Method 300 can be performed using system 50, though it should beunderstood that variations to both system 50 and method 300 arecontemplated. Method 300 is particularly applicable once method 200 hasbeen performed.

Beginning at step 310, a request is received to top-up a prepaidaccount. This request can be effected in the usual manner—for example,subscriber S purchases a prepaid card for a predefined amount and usesdevice 54 to enter in an appropriate sequence of digits unique to theprepaid card which amount to a set of instructions to add the predefinedamount to the prepaid account associated with subscriber S. (Of course,other methods for making a top-up request are also contemplated,including via an Internet website, an interactive voice response (“IVR”)prompt system, etc.)

Next at step 315, a determination is made as to whether there is anyoutstanding debit associated with subscriber S. For example, assume thatduring previous performance of step 200 for subscriber S that the methodended directly after step 235, determining that no emergency top up waspermitted. In this example, the determination at step 315 would be “no”and method 300 would advance from step 315 to step 320 and the prepaidaccount for subscriber S would be topped up at prepaid server 90 with anamount that directly corresponded to the predefined amount on theprepaid wireless card referenced in relation to step 310.

Referring again to step 315, however, assume as another example thatsubscriber S had previously been permitted to invoke steps 240-250 ofmethod 200, in which case a debit amount as set at 245 would beassociated with subscriber S. In this example, a “yes” determinationwould be reached at step 315 and method 300 would advance from step 315to step 325.

At step 325, the top up amount from step 310 is first applied toclearing any accumulated debit that was generated previously at step 245of method 200. Thus, for example, if the debit from step 245 was forfive dollars, and the predefined amount from step 310 was for twentydollars, then the predefined amount from step 310 would be reduced tofifteen dollars. At this point in time the serial emergency top-upcounter will also be reset to zero. Next, at step 335 (which is anoptional step) a service fee amount is applied from the remaining top uppredefined amount. Thus, if the service fee amount was one dollar, thenthe predefined amount from step 310, and as adjusted at step 325, wouldbe further reduced from fifteen dollars by one dollar to fourteendollars.

Next, at step 345, a determination is made if there is any top-up amountremaining. If there is no amount remaining (e.g. all amounts from step310 were consumed by step 325 and/or step 335) then the determination atstep 345 is “no” and method 300 ends. If the determination at step 345is “yes”, then method 300 advances from step 345 to step 320 and anyremaining top up balance is applied in the usual manner. In the aboveexample, where fourteen dollars was remaining, then the prepaid accountbelonging to subscriber S in server 90 would be topped up by fourteendollars only, instead of the full twenty dollars associated with theprepaid card referenced above in relation to step 310.

It should be understood that methods 200 and 300 can be readily modifiedfor use in a roaming configuration and methods 200 and 300 can operatesubstantially as described above.

Methods 200 and 300 only reflect one possible implementation for system50. In another embodiment, subscriber S can be associated with aplurality of different billing profiles such that different billingprofiles are selected and invoked based on a flexible range of criteria.An example of this embodiment is presented in FIG. 4 as method 400.While method 400 can be implemented on system 50, it should again beunderstood that method 400 can be implemented on other networkconfigurations other than system 50.

Beginning at step 410, a request is received to make or receive a call(or to invoke any other type service supported by device 54 and network58). Again, using system 50, step 410 is effected in much the samemanner as step 410 described above. Next, at step 415 a billing profileis selected. Step 415 is effected by billing profile manager 74. In thisembodiment, gateway 78 is generally configured to intercept or otherwisebe notified of a call request initiated from or received at a mobiledevice 54 that participates in the multiple billing profile serviceassociated with method 400 prior to call completion. Those skilled inthe art will recognize that gateway 78 can intercept or otherwise benotified of a call request via a number of mechanism, including but notlimited to, Intelligent Network based mechanisms including thoseprescribed by 3GPP, 3GPP2, ANSI, ITU, ETSI, and TIA,session-notification mechanisms via SIP, RADIUS or DIAMETER (for examplethe ISC (IMS Service Control), Ro, Rx, Gx, and Gy interfaces prescribedby the 3GPP and 3GPP2), as well as Application Programming Interfacebased mechanisms as prescribed by industry bodies such as the OpenMobile Alliance, Parlay, and the Java Community Process. (Gateway 78need not participate in any calls that do not involve the multiplebilling profile service.)

Billing manager database 86 is configured to maintain a plurality ofbilling profiles associated with subscriber S, and engine 82 isconfigured to select one of those billing profiles based on predefinedcriteria. Alternatively, billing manager database 86 can retrieve therelevant billing profile attributes via a profile server implementedaccording to the teachings of U.S. patent application Ser. No.11/516,308 entitled Method And System For Active Profile Server filedSep. 6, 2006, the contents of which are incorporated herein byreference. The structure and content of billing profiles and criteriaare not particularly confined. However, Table I shows an example set ofbilling profiles.

TABLE I Exemplary Billing Profiles Billing Profile Billing EntityCriterion 1 Criterion 2 Criterion 3 Account 1 X Corporation Time of dayis Telephony Calls within Postpaid between 9 AM service only NorthAmerica Account and only Identifier X1 5 PM Monday through Friday 2Subscriber S Time of day Telephony Empty Postpaid does not equal serviceonly Account Criterion 1 Identifier S1 3 Subscriber S Time of day DataEmpty Prepaid does not equal services Account Criterion 1 exceptIdentifier S2 Mobile TV 4 Subscriber S Time of day Mobile TV EmptyPostpaid does not equal Account Criterion 1 Identifier Sponsor_1

Table I can be useful in a situation where a subscriber S uses device 54for both work and personal purposes. For work uses, billing profile 1 isinvoked and X Corporation (the employer of subscriber S) is billeddirectly. For personal uses, billing profiles 2, 3, and 4 are invokedand subscriber S is billed directly. X Corporation is billed for alltelephone calls within North America that are made between 9 AM and 5 PMMonday through Friday. Applicable charges for services used inconnection with X Corporation are directed to a postpaid account asidentified via Account Identifier X1. All other types of calls andservices are not permitted. The Subscriber S is billed for all calls orother services that are made during any of the times that are not madebetween 9 AM and 5 PM Monday through Friday. Applicable charges forvoice-based calls made by Subscriber S in these timeframes are directedto a postpaid account as identified via Account Identifier S1.Applicable charges for data services except Mobile TV made by SubscriberS in these timeframes are directed to a prepaid account as identifiedvia Account Identifier S2. Applicable charges for Mobile TV servicesmade by Subscriber S in these timeframes are directed to a post-paidaccount as identified via Account Identifier Sponsor 1. Note that thelast entry may be used to identify a sponsored or promotional serviceoffering.

Thus, assuming that step 415 is being performed using Table I, then thecriteria in Table I would be used to select an appropriate billingprofile and associated billing entity. Thus, if the call at step 410 wasinitiated at 9:30 AM on a Tuesday morning, then Billing Profile 1 wouldbe selected. However, if the call at step 410 was initiated on theweekend, then Billing Profile 2, 3, or 4 would be selected.

Next, at step 420, the selected billing profile is invoked. In theexample associated with system 50, depending on whether the BillingProfile indicated that the service was associated with a prepaid orpostpaid account, billing engine 82 will generate call detail records(or the like) relative to any calls that are made and completedaccording to method 400. These call detail records can be used by anevent record based billing system 100 connected to the networkconfigured to debit an account associated with the subscriber. In thepresent exemplary embodiment, billing engine 82 may also be configuredto modify the account according to said billing profile in order tocause the network 58 to selectively permit or deny said service request.For example, the billing engine 82 may access prepaid server 90 toprovide a balance and to establish any calling restrictions in prepaidserver 94 that are consistent with the selected billing profile. In thepresent exemplary embodiment, billing engine 82 may also make subscriberS and device 54 appear to be a prepaid subscriber for which calls arecompleted and managed in the usual manner. To the extent that an accountdoes not exist in the prepaid server 94 or event record based billingsystem 100, the billing profile manager 74 may create and maintain avirtual account with applicable calling restrictions in the billingmanager database 86 or in the prepaid server 94. To the extent that theservice logic in the prepaid server 94 or event record based billingsystem 100 cannot accommodate for any configured criteria, the billingprofile manager 74 may be optionally configured to execute theapplicable service logic and only debit the prescribed account. In thismanner, network 58, the event record based billing system, and prepaidserver 90 need not be substantially modified, and likewise, subscriber Scan roam—while at the same time allowing different billing profiles toactually be effected for the one subscriber S and device 54.

Thus, at step 425, a determination is made as to whether the callrequested at step 410 conforms with the billing profile. In general,call processing logic will verify that the requested call will complywith all of the criteria in the selected billing profile. For example,if billing profile 1 was selected then Criterion 2 and Criterion 3 mustalso be complied with in order for any call to be completed. Thus, atstep 425, in this example, only a call from step 410 that is withinNorth America would be permitted—a SMS would not be permitted, or a calloutside North America would not be permitted.

If the call is not permitted then method 400 advances from step 425 to430 and the call is refused. If the call is permitted then method 400advances from step 425 to 435 and the call is permitted and billingentries for the appropriate billing entity are updated. Step 435 can beeffected in part by network 58 and billing profile manager 74 inconjunction with prepaid server 90 working together to complete the calland to decrement a prepaid balance stored on server 90 accordingly. Theremainder of step 435 is effected by billing engine 82, which examinesthe remaining prepaid balance on server 90 at the termination of thecall (or periodically throughout the call, if needed). Alternatively,step 435 can be effected in part by network 58 and billing profilemanager 74 in conjunction with event record based billing system 100 viathe generation and processing of call detail records.

The previous discussion of method 400 was simplified for ease ofexplanation. It should be understood that billing profiles can be muchmore complex than the billing profiles in Table I. Other billingprofiles can include: whether or not a billing entity is billed on aprepaid or post-paid basis, or hybrids thereof; various types ofservices that can be billed on the profile and indeed different profilescan be invoked depending on the type of service that is requested atstep 410.

It should now be understood that the foregoing present certain exemplaryembodiments, but modifications, variations, subsets and/or combinationsthereof are contemplated. For example, it should be understood thatmethod 400 can be implemented on a version of system 50 that does notinclude prepaid server 90 or event record based billing system 100.

1. A billing profile management system comprising: a network configuredto a fulfill service request on behalf of a mobile device; a prepaidserver connected to said network configured to debit a prepaid accountassociated for said mobile device based on fulfillment of said servicerequest by said network; and a billing manager connected to said networkand said prepaid server configured to maintain another accountassociated with said mobile device; said billing manager configured toupdate said prepaid account based on billing criteria associated withsaid mobile device.
 2. The billing profile management system of claim 1wherein said billing manager is configured to update said prepaid serverto reflect a positive balance in said prepaid account while maintaininga corresponding debit balance in said another account.
 3. The billingprofile management system of claim 2 wherein said billing manager isconfigured to perform said update based on a request from said mobiledevice.
 4. The billing profile management system of claim 3 wherein saidbilling manager includes a message gateway and said request is apredefined string.
 5. The billing profile management system of claim 4wherein the message gateway is a USSD (Unstructured SupplementaryService Data) gateway and said request is a predefined USSD string.
 6. Abilling profile management system comprising: a network configured tofulfill a service request on behalf of a mobile device; a billingmanager connected to said network; said billing manager configured tomaintain a plurality of different billing profiles associated with saidmobile device; each said billing profile including at least a billingentity and a criterion for selecting said billing profile; said billingmanager configured to select an appropriate one of said billing profilesbased on said service request from said mobile device and to bill saidbilling entity respective to said selected billing profile.
 7. Thesystem of claim 5 further comprising a billing system connected to saidnetwork configured to debit an account associated for said mobile devicebased on fulfillment of said service requests by said network; saidbilling manager configured to modify said account according to saidbilling profile in order to cause said network to selectively permit ordeny said service request.
 8. The system of claim 7 wherein the billingsystem is a prepaid server or an event record based billing system.
 9. Amethod for emergency top-up of a subscriber balance associated with amobile device; said subscriber balance optionally applicable to aservice that can be performed on said mobile device; said methodcomprising: receiving a request for emergency top-up of said subscriberbalance; determining if said request is permitted; debiting an accountassociated with said subscriber. performing said top up if said requestis permitted.
 10. The method of claim 9 further comprising, prior tosaid receiving: receiving a request to fulfill a service on behalf of amobile device associated with said subscriber; examining said subscriberbalance associated with said mobile device; if said balance issufficient then fulfilling said service; and if said balance isinsufficient sending a notification to said subscriber.
 11. The methodof claim 9 wherein said request is in the form of a UnstructuredSupplementary Service Data (USSD) string.
 12. The method of claim 9wherein said request is received from said mobile device.
 13. The methodof claim 9 wherein said determining comprises whether a profileassociated with said subscriber balance permits emergency top-up. 14.The method of claim 9 wherein said determining comprises determining atotal number of ones of said requests that are permitted and whethersaid total number has been reached or exceeded.
 15. The method of claim9 wherein said subscriber balance is associated with a prepaid account.16. The method of claim 15 further comprising: receiving a request topup said subscriber prepaid account including a top-up amount;determining a debit amount associated with said account; applying atleast a portion of said top-up amount to said debit amount in order toreduce said debit amount; and, applying any remaining portion of saidtop-up amount to said prepaid account.
 17. A method for emergency top-upof a pre-paid account associated with a mobile device; said subscriberbalance optionally applicable to a service that can be performed on saidmobile device; said method comprising: receiving a request from saidmobile device for emergency top-up of said pre-paid account; determiningwhether a profile associated with said pre-paid account permitsemergency top-up; determining a total number of ones of said requeststhat are permitted and whether said total number has been reached orexceeded; if said request is permitted according to said determiningsteps then: performing said top-up to said pre-paid account; applying adebit amount corresponding to at least said top-up amount to asubscriber account separate from said pre-paid account.
 18. The methodof claim 17 wherein said debit amount includes said top-up amount and aservice fee.
 19. A method of billing profile management comprising:receiving a request to fulfill a service on behalf of a mobile deviceassociated with a subscriber; selecting one of a plurality of billingprofiles associated with said subscriber; said selecting based oncriteria associated with said subscriber; and, permitting or denyingsaid request based on whether said service conforms with said selectedbilling profile.